% This file was created with JabRef 2.7b.
% Encoding: UTF8

@INPROCEEDINGS{Baldoni2006,
  author = {R. Baldoni and C. Marchetti and S. Tucci Piergiovanni and A. Virgillito},
  title = {{Fully Distributed Three-Tier Active Software Replication}},
  booktitle = {IEEE Transactions on Parallel and Distributed Systems, 17(7), 633-645},
  year = {2006},
  month = {6},
  abstract = {Keeping strongly consistent the state of the replicas of a software
	service deployed across a
	
	distributed system prone to crashes and with highly unstable message
	transfer delays (e.g. the Internet),
	
	is a real practical challenge. The solution to this problem is subject
	to the FLP impossibility result, and
	
	thus there is a need for “long enough” periods of synchrony with time
	bounds on process speeds and
	
	message transfer delays to ensure deterministic termination of any
	run of agreement protocols executed
	
	by replicas. This behavior can be abstracted by a partially synchronous
	computational model. In this
	
	setting, before reaching a period of synchrony, the underlying network
	can arbitrarily delay messages
	
	and these delays can be perceived as false failures by some timeout-based
	failure detection mechanism
	
	leading to unexpected service unavailability. This paper proposes
	a fully distributed solution for active
	
	software replication based on a three-tier software architecture well-suited
	to such a difficult setting. The
	
	formal correctness of the solution is proved by assuming the middle-tier
	runs in a partially synchronous
	
	distributed system. This architecture separates the ordering of the
	requests coming from clients, executed
	
	by the middle-tier, from their actual execution, done by replicas,
	i.e., the end-tier. In this way clients
	
	can show up in any part of the distributed system and replica placement
	is simplified, since only the
	
	middle-tier has to be deployed on a well-behaving part of the distributed
	system that frequently respects
	
	synchrony bounds. This deployment permits a rapid timeout tuning reducing
	thus unexpected service
	
	unavailability.},
  file = {Baldoni2006.pdf:pdf\\Baldoni2006.pdf:PDF},
  owner = {nebojsa.trninic},
  timestamp = {2012.10.08},
  url = {http://www.dis.uniroma1.it/~midlab}
}

@ARTICLE{Baldoni2003,
  author = {R. Baldoni and C. Marchetti and A. Virgillito},
  title = {{Enhancing Availability of Cooperative Applications through Interoperable
	Middleware}},
  journal = {Journal of Information Science and Engineering, Special Issue on
	Parallel and Distributed Systems, 2003},
  year = {2003},
  volume = {1},
  number = {19},
  month = {6},
  abstract = {Cooperative information systems are characterized by distribution,
	high heterogeneity
	
	and scale. Therefore they require interoperable, dependable services
	on top of
	
	which the development of cooperative application can take place. This
	paper studies, in
	
	the context of the Unitary Network of the Italian Public Administration,
	the problem of
	
	increasing the availability of the services exported by a cooperating
	entity through interoperable
	
	middleware. In particular we show how a Fault Tolerant CORBA compliant
	
	system, namely the Interoperable Replication Logic (IRL), can be used
	to increase such
	
	availability by building a replicated cooperative gateway that wraps
	enterprise
	
	cooperative applications.},
  file = {Baldoni2003.pdf:pdf\\Baldoni2003.pdf:PDF},
  keywords = {cooperative information systems, fault tolerance, object replication,
	CORBA,
	
	FT-CORBA, middleware platforms},
  owner = {nebojsa.trninic},
  timestamp = {2012.06.01},
  url = {http://www.dis.uniroma1.it/~midlab}
}

@ELECTRONIC{Barney2012a,
  author = {Blaise Barney},
  month = {07},
  year = {2012},
  title = {Introduction to Parallel Computing},
  organization = {Lawrence Livermore National Laboratory},
  note = {UCRL-MI-133316},
  url = {https://computing.llnl.gov/tutorials/parallel_comp/},
  abstract = {This tutorial is the first of eight tutorials in the 4+ day "Using
	LLNL's Supercomputers" workshop. It is intended to provide only a
	very quick overview of the extensive and broad topic of Parallel
	Computing, as a lead-in for the tutorials that follow it. As such,
	it covers just the very basics of parallel computing, and is intended
	for someone who is just becoming acquainted with the subject and
	who is planning to attend one or more of the other tutorials in this
	workshop. It is not intended to cover Parallel Programming in depth,
	as this would require significantly more time. The tutorial begins
	with a discussion on parallel computing - what it is and how it's
	used, followed by a discussion on concepts and terminology associated
	with parallel computing. The topics of parallel memory architectures
	and programming models are then explored. These topics are followed
	by a series of practical discussions on a number of the complex issues
	related to designing and running parallel programs. The tutorial
	concludes with several examples of how to parallelize simple serial
	programs.},
  file = {Parallel:html\\13_Introduction to Parallel Computing.htm:URL},
  owner = {nebojsa.trninic},
  timestamp = {2012.07.16}
}

@ELECTRONIC{Barney2012b,
  author = {Blaise Barney},
  year = {2012},
  title = {POSIX Threads Programming},
  organization = {Lawrence Livermore National Laboratory},
  note = {UCRL-MI-133316},
  url = {https://computing.llnl.gov/tutorials/pthreads/},
  abstract = {In shared memory multiprocessor architectures, such as SMPs, threads
	can be used to implement parallelism. Historically, hardware vendors
	have implemented their own proprietary versions of threads, making
	portability a concern for software developers. For UNIX systems,
	a standardized C language threads programming interface has been
	specified by the IEEE POSIX 1003.1c standard. Implementations that
	adhere to this standard are referred to as POSIX threads, or Pthreads.
	
	
	The tutorial begins with an introduction to concepts, motivations,
	and design considerations for using Pthreads. Each of the three major
	classes of routines in the Pthreads API are then covered: Thread
	Management, Mutex Variables, and Condition Variables. Example codes
	are used throughout to demonstrate how to use most of the Pthreads
	routines needed by a new Pthreads programmer. The tutorial concludes
	with a discussion of LLNL specifics and how to mix MPI with pthreads.
	A lab exercise, with numerous example codes (C Language) is also
	included.},
  file = {POSIX Threads Programming:html\\14_POSIX Threads Programming.htm:URL},
  owner = {nebojsa.trninic},
  timestamp = {2012.07.17}
}

@INPROCEEDINGS{Atlagic2012,
  author = {Branislav Atlagic, Mihaly Sagi, Dejan Milinkov, Bojan Bogovac, Stanko
	Culaja},
  title = {Model-based Approach to the Development of SCADA applications},
  booktitle = {19th Annual IEEE International Conference and Workshops on the Engineering
	of Computer Based Systems},
  year = {2012},
  address = {21000 Novi Sad, Serbia},
  month = {April 11-13},
  organization = {Faculty of Technical Sciences at University of Novi Sad},
  publisher = {IEEE},
  note = {Workshop 3
	
	http://tab.computer.org/ecbs/2012/ (ići na workshops)
	
	http://tab.computer.org/ecbs/2012/workshops.html (WS3)
	
	http://www2.engr.arizona.edu/~sprinkjm/research/mbd2012/},
  file = {Model-based Approach to the Development of SCADA applications:doc\\11 Model-based Approach to the Development of SCADA applications.docx:Word},
  owner = {nebojsa.trninic},
  timestamp = {2012.07.18},
  url = {http://www2.engr.arizona.edu/~sprinkjm/research/mbd2012/}
}

@INPROCEEDINGS{Cotroneo2011,
  author = {Cotroneo, Domenico and Natella, Roberto and Pietrantuono, Roberto
	and Russo, Stefano},
  title = {Software Aging and Rejuvenation: Where We Are and Where We Are Going},
  booktitle = {Proceedings of the 2011 IEEE Third International Workshop on Software
	Aging and Rejuvenation},
  year = {2011},
  series = {WOSAR '11},
  pages = {1--6},
  address = {Washington, DC, USA},
  publisher = {IEEE Computer Society},
  abstract = {After 16 years, a significant body of knowledge has been established
	in the area of Software Aging and Rejuvenation (SAR). In this paper,
	we survey papers about SAR that appeared in IEEE conferences and
	journals, identify where SAR research has been mostly focused, and
	highlight some aspects deserving more attention, with the aim to
	provoke a constructive discussion among SAR researches about where
	SAR has arrived and where it should be headed in the next future.},
  acmid = {2122238},
  doi = {10.1109/WoSAR.2011.15},
  file = {Cotroneo2011.pdf:pdf\\Cotroneo2011.pdf:PDF},
  isbn = {978-0-7695-4616-2},
  keywords = {Software Aging, Software Rejuvenation, Survey},
  numpages = {6},
  owner = {nebojsa.trninic},
  timestamp = {2012.06.02},
  url = {http://dx.doi.org/10.1109/WoSAR.2011.15}
}

@BOOK{Coulouris2011,
  title = {Distributed Systems: Concepts and Design},
  publisher = {Addison-Wesley Publishing Company},
  year = {2011},
  author = {Coulouris, George and Dollimore, Jean and Kindberg, Tim and Blair,
	Gordon},
  address = {USA},
  edition = {5th},
  abstract = {Broad and up-to-date coverage of the principles and practice in the
	fast moving area of Distributed Systems. Distributed Systems provides
	students of computer science and engineering with the skills they
	will need to design and maintain software for distributed applications.
	It will also be invaluable to software engineers and systems designers
	wishing to understand new and future developments in the field. From
	mobile phones to the Internet, our lives depend increasingly on distributed
	systems linking computers and other devices together in a seamless
	and transparent way. The fifth edition of this best-selling text
	continues to provide a comprehensive source of material on the principles
	and practice of distributed computer systems and the exciting new
	developments based on them, using a wealth of modern case studies
	to illustrate their design and development. The depth of coverage
	will enable readers to evaluate existing distributed systems and
	design new ones.},
  isbn = {0132143011, 9780132143011},
  owner = {lucky},
  timestamp = {2012.12.27}
}

@ELECTRONIC{Coutinho1995,
  author = {Jason Coutinho and Stephen Martin and Gary Samata and Steve Tapley
	and Daniel Wilkin},
  month = {May},
  year = {1995},
  title = {Fieldbus Tutorial},
  organization = {Curtin University of Technology},
  url = {http://kernow.curtin.edu.au/www/Fieldbus/fieldbus.htm},
  file = {:./html/Coutinho1995/Fieldbus Tutorial.htm:CHM},
  owner = {lucky},
  timestamp = {2013.04.30}
}

@INPROCEEDINGS{Gurtov2003,
  author = {Andrei Gurtov},
  title = {Responding to spurious timeouts in TCP},
  booktitle = {In Proc. of IEEE INFOCOM’03},
  year = {2003},
  abstract = {Abstract- Delays on Internet paths, especially including wireless
	links, can be highly variable. On the other hand, a current trend
	for modern TCPs is to deploy a fine-grain retransmission timer with
	a lower minimum timeout value than 1 s suggested by RFC2988. Spurious
	TCP timeouts cause unnecessary retransmissions and congestion control
	back-off. The Eifel algorithm detects spurious TCP timeouts and recovers
	by restoring the connection state saved before the timeout. This
	paper presents an enhanced version of the Eifel response to spurious
	timeouts and illustrates its performance benefits on paths with a
	high delay-bandwidth product. The refinements concern the following
	issues (1) an efficient operation in presence of packet losses (2)
	appropriate restoration of congestion control, and (3) adapting the
	retransmit timer to avoid further spurious timeouts. In our simulations
	the Eifel algorithm on paths with a high delay-bandwidth product
	can increase throughput by up to 250 % and at the same decrease the
	load on the network by 3%. The proposed response also shows adequate
	performance on heavily congested paths.},
  file = {Gurtov2003.pdf:pdf\\Gurtov2003.pdf:PDF},
  owner = {nebojsa.trninic},
  timestamp = {2012.05.22},
  url = {http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.81.5528}
}

@TECHREPORT{Kalapatapu2004,
  author = {Kalapatapu, R.},
  title = {Scada Protocols and Communication Trends},
  institution = {ISA EXPO},
  year = {2004},
  abstract = {The present day Supervisory Control and Data Acquisition (SCADA) systems
	consisting of SCADA hosts, Remote Terminal Units (RTUs) and field
	devices monitor and control process equipment and systems from multiple
	locations and exchange data from various distributed control systems
	along the local and wide area networks. SCADA system operation involves
	real time data exchange from the field devices as well as with other
	control systems such as DCS (Distributed Control and PI (Plant Information)
	systems. A typical RTU in the field contains a central processor,
	set of Input /Output modules and communication devices to connect
	to field devices. The RTUs are similar to Programmable Logic Controllers
	(PLCs). PLCs are used with in a local area such as factory floor
	and are connected together usually by a local area network; where
	as RTUs are used in remote locations and connected by a Wide Area
	Network; Other wise both have CPU, I/O units and communication ports.
	Hence most of the discussion in this paper also applicable to PLC
	systems. These RTUs in turn are connected to the SCADA control system
	servers and workstations, as well as other local and remote area
	networks by means of phone lines, cables, leased lines, radios, fiber
	optics and/or a combination of these based on availability at each
	of these sites.},
  file = {:/home/jester/mydev/invoker-of-background-commands/doc/pdf/Kalapatapu2004.pdf:PDF},
  owner = {lucky},
  timestamp = {2012.12.27},
  url = {http://www.isa.org/Template.cfm?Section=Technical_Paper_Collections&Template=/Ecommerce/ProductDisplay.cfm&ProductID=7645}
}

@INPROCEEDINGS{Kesselman2005,
  author = {Kesselman, Alex and Mansour, Yishay},
  title = {Optimizing TCP retransmission timeout},
  booktitle = {Proceedings of the 4th international conference on Networking - Volume
	Part II},
  year = {2005},
  series = {ICN'05},
  pages = {133--140},
  address = {Berlin, Heidelberg},
  publisher = {Springer-Verlag},
  abstract = {Delay spikes on Internet paths can cause spurious
	
	TCP timeouts leading to signicant throughput degradation.
	
	However, if TCP is too slow to detect that a retransmission is necessary,
	
	it can stay idle for a long time instead of transmitting. The
	
	goal is to nd a Retransmission Timeout (RTO) value that balances
	
	the throughput degradation between both of these cases. In
	
	the current TCP implementations, RTO is a function of the Round
	
	Trip Time (RTT) alone. We show that the optimal RTO that maximizes
	
	the TCP throughput need to depend also on the TCP window
	
	size. Intuitively, the larger the TCP window size, the longer
	
	the optimal RTO.We derive the optimal RTO for several RTT distributions.
	
	An important advantage of our algorithm is that it can
	
	be easily implemented based on the existing TCP timeout mechanism.},
  acmid = {2140303},
  doi = {10.1007/978-3-540-31957-3_17},
  file = {Kesselman2005.pdf:pdf\\Kesselman2005.pdf:PDF},
  isbn = {3-540-25338-6, 978-3-540-25338-9},
  location = {Reunion Island, France},
  numpages = {8},
  owner = {nebojsa.trninic},
  review = {This one I like very much. RTO depends on past RTTs. If RTO is too
	short, then spurious retransmissions can occur, meaning packets are
	retransmitted when original reached destination, but this congests
	the network unnecessarily (250% in some cases), while in case of
	problem packet is retransmitted quickly. If RTO is long, then network
	is not congested, but in case when packet is lost, it takes a long
	time to decide to retransmitt it. This article recognizes the problem
	and claims that optimal formula needs to include past RTTs and TCP
	window size (W), i.e. RTO = f ( RTTs[], W ). This one resembles "Optimal
	Retrial and Timeout Strategies for Accessing Network Resources" [Libman2002].
	Therefore, it is crucial for the TCP performance to find a Retransmission
	TimeOut (RTO) value that is an equilibrium point balancing between
	both of these cases (too short and too long). The longer TCP window
	size, the longer RTO should be selected in order to avoid spurious
	timeouts. Good conclusion chapter in the end, i.e. VIII CONCLUDING
	REMARKS.},
  timestamp = {2012.05.18},
  url = {http://dx.doi.org/10.1007/978-3-540-31957-3_17}
}

@ARTICLE{Libman2002,
  author = {Libman, Lavy and Orda, Ariel},
  title = {Optimal retrial and timeout strategies for accessing network resources},
  journal = {IEEE/ACM Trans. Netw.},
  year = {2002},
  volume = {10},
  pages = {551--564},
  number = {4},
  month = aug,
  abstract = {The notion of timeout (namely, the maximal time to wait before retrying
	an action) turns up in many networking contexts, such as packet transmission,
	connection establishment, etc. Usage of timeouts is encountered especially
	in large-scale networks, where negative acknowledgments (NACKs) on
	failures have significantly higher delays than positive acknowledgments
	(ACKs) and frequently are not employed at all. Selection of a proper
	timeout involves a tradeoff between waiting too long and loading
	the network needlessly by waiting too little. The common approach
	is to set the timeout to a large value, such that, unless the action
	fails, it is acknowledged within the timeout duration with a high
	probability. This approach is conservative and leads to overly long,
	far from optimal, timeouts.We take a quantitative approach with the
	purpose of computing and studying the optimal timeout strategy. The
	above tradeoff is modeled by introducing a "cost" per unit time (until
	success) and a "cost" per repeated attempt. The optimal timeout strategy
	is then defined as one that a selfish user would follow to minimize
	its expected cost. We discuss the various practical interpretations
	that these costs may have. We then derive the formulas for the optimal
	timeout values and study some of their fundamental properties. In
	particular, we identify the conditions for making parallel attempts
	from the outset to be worthwhile. In addition, we demonstrate a striking
	property of positive feedback. This motivates us to study the interaction
	resulting when many users selfishly apply the optimal timeout strategy;
	specifically, we use a noncooperative game model and show that it
	suffers from an inherent instability problem. Some implications of
	these results on network design are discussed.},
  acmid = {581872},
  address = {Piscataway, NJ, USA},
  doi = {10.1109/TNET.2002.801412},
  file = {Libman2002.pdf:pdf\\Libman2002.pdf:PDF},
  issn = {1063-6692},
  issue_date = {August 2002},
  keywords = {connection establishment, network pricing, noncooperative games, packet
	retransmission, timeout strategy},
  numpages = {14},
  owner = {nebojsa.trninic},
  publisher = {IEEE Press},
  review = {Presents calculation how to determine optimal timeout strategy given
	the network parameters (network load, network mean request failure
	rate and network load when clients are resending).},
  timestamp = {2012.05.15},
  url = {http://dx.doi.org/10.1109/TNET.2002.801412}
}

@ARTICLE{Ludwig2000,
  author = {Ludwig, Reiner and Katz, Randy H.},
  title = {The Eifel algorithm: making TCP robust against spurious retransmissions},
  journal = {SIGCOMM Comput. Commun. Rev.},
  year = {2000},
  volume = {30},
  pages = {30--36},
  number = {1},
  month = jan,
  abstract = {We propose an enhancement to TCP's error recovery scheme, which we
	call the Eifel algorithm. It eliminates the retransmission ambiguity,
	thereby solving the problems caused by spurious timeouts and spurious
	fast retransmits. It can be incrementally deployed as it is backwards
	compatible and does not change TCP's congestion control semantics.
	In environments where spurious retransmissions occur frequently,
	the algorithm can improve the end-to-end throughput by several tens
	of percent. An exact quantification is, however, highly dependent
	on the path characteristics over time. The Eifel algorithm finally
	makes TCP truly wireless-capable without the need for proxies between
	the end points. Another key novelty is that the Eifel algorithm provides
	for the implementation of a more optimistic retransmission timer
	because it reduces the penalty of a spurious timeout to a single
	(in the common case) spurious retransmission.},
  acmid = {505692},
  address = {New York, NY, USA},
  doi = {10.1145/505688.505692},
  file = {Ludwig2000.pdf:pdf\\Ludwig2000.pdf:PDF},
  issn = {0146-4833},
  issue_date = {January 2000},
  numpages = {7},
  owner = {nebojsa.trninic},
  publisher = {ACM},
  timestamp = {2012.05.21},
  url = {http://doi.acm.org/10.1145/505688.505692}
}

@ARTICLE{Ma2006,
  author = {Ma, Liangping and Barner, Kenneth E. and Arce, Gonzalo R.},
  title = {Statistical analysis of TCP's retransmission timeout algorithm},
  journal = {IEEE/ACM Trans. Netw.},
  year = {2006},
  volume = {14},
  pages = {383--396},
  number = {2},
  month = apr,
  abstract = {The retransmission timeout (RTO) algorithm of Transmission Control
	Protocol (TCP), which sets a dynamic upper bound on the next round-trip
	time (RTT) based on past RTTs, plays an important role in reliable
	data transfer and congestion control of the Internet. A rigorous
	theoretical analysis of the RTO algorithm is important in that it
	provides insight into the algorithm and prompts optimal design strategies.
	Nevertheless, such an analysis has not been conducted to date. This
	paper presents such an analysis from a statistical approach. We construct
	an auto-regressive (AR) model for the RTT processes based on experimental
	results that indicate: 1) RTTs along a certain path in the Internet
	can be modeled by a shifted Gamma distribution and 2) the temporal
	correlation of RTTs decreases quickly with lag. This model is used
	to determine the average reaction time and premature timeout probability
	for the RTO algorithm. We derive a closed-form expression for the
	first measure and a formula for numerically calculating the second.
	Both measures are validated through tests on simulated and real RTT
	data. The theoretical analysis strengthens a number of observations
	reported in past experiment-oriented studies.},
  acmid = {1217631},
  address = {Piscataway, NJ, USA},
  doi = {10.1109/TNET.2006.872577},
  file = {Ma2006.pdf:pdf\\Ma2006.pdf:PDF},
  issn = {1063-6692},
  issue_date = {April 2006},
  keywords = {auto-regressive models, gamma distribution, lognormal distribution,
	retransmission timeout (RTO), round-trip time (RTT), tCP, timeout},
  numpages = {14},
  owner = {nebojsa.trninic},
  publisher = {IEEE Press},
  review = {Shows dependence of RTO on past RTTs and finds formulas based on assumptions
	given.},
  timestamp = {2012.05.17},
  url = {http://dx.doi.org/10.1109/TNET.2006.872577}
}

@MISC{rfc2349,
  author = {G. Malkin and A. Harkin},
  title = {{TFTP Timeout Interval and Transfer Size Options}},
  howpublished = {RFC 2349 (Draft Standard)},
  month = may,
  year = {1998},
  abstract = {The Trivial File Transfer Protocol [1] is a simple, lock-step, file
	transfer protocol which allows a client to get or put a file onto
	a remote host.},
  file = {rfc2349.txt:rfc\\rfc2349.txt:Text},
  number = {2349},
  organization = {Internet Engineering Task Force},
  owner = {nebojsa.trninic},
  publisher = {IETF},
  review = {ntrna>>> Stresses the importance of having timeout. Originally TFT
	in RFC 1350 dated July 1992, did not have timeout option, but it
	was introduced in 1998 in this RFC 2349.
	
	
	http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol
	
	RFC 906 – Bootstrap loading using TFTP, R. Finlayson, June 1984.
	
	RFC 1350 – TFTP Protocol (revision 2), K. R. Sollins, July 1992. (This
	superseded the preceding, RFC 783 and earlier FTP RFCs back to the
	original IEN 133)
	
	RFC 1785 – TFTP Option Negotiation Analysis, G. Malkin, A. Harkin,
	March 1995.
	
	RFC 2090 – TFTP Multicast Option, A. Emberson, February 1997. (Status:
	Experimental)
	
	RFC 2347 – TFTP Option Extension, G. Malkin, A. Harkin, May 1998.
	(This superseded the preceding, RFC 1782)
	
	RFC 2348 – TFTP Blocksize Option, G. Malkin, A. Harkin, May 1998.
	(This superseded the preceding, RFC 1783)
	
	RFC 2349 – TFTP Timeout Interval and Transfer Size Options, G. Malkin,
	A. Harkin, May 1998 (This superseded the preceding, RFC 1784).
	
	RFC 3617 – Uniform Resource Identifier (URI) Scheme and Applicability
	Statement for the Trivial File Transfer Protocol (TFTP), E. Lear,
	October 2003.},
  series = {Request for Comments},
  timestamp = {2012.05.19},
  url = {http://www.ietf.org/rfc/rfc2349.txt}
}

@ARTICLE{Mancina2009,
  author = {Mancina, Antonio and Faggioli, Dario and Lipari, Giuseppe and Herder,
	JorritN. and Gras, Ben and Tanenbaum, Andrew S.},
  title = {Enhancing a dependable multiserver operating system with temporal
	protection via resource reservations},
  journal = {Real-Time Systems},
  year = {2009},
  volume = {43},
  pages = {177-210},
  abstract = {Nowadays, microkernel-based systems are getting studied and adopted
	with a renewed interest in a wide number of IT scenarios. Their advantages
	over classical monolithic solutions mainly concern the dependability
	domain. By being capable of dynamically detect and solve non-expectedbehaviours
	within its core components, a microkernel-based OS would eventually
	run forever with no need to be restarted. Dependability in this context
	mainly aims at isolating components from a spatial point of view:
	a microkernel-based system may definitely not be adoptedin the context
	of real-time environments, simply basing on this kind of protection
	only.
	
	One of the most active real-time research areas concerns adding temporal
	protection mechanisms to general purpose operating systems. By making
	use of such mechanisms, these systems become suitable for being adopted
	in the context of time-sensitive domains. Microkernel-based systems
	have always been thought of as a kind of platform not suited to real-time
	contexts, due to the high latencies introduced by the message passing
	technique as the only inter-process communication (IPC) facility
	within the system. With computer performances growing at a fairly
	high rate, this overhead becomes negligible with respect to the typical
	real-time processing times.
	
	In the last years, many algorithms belonging to the class of the so-called
	Resource Reservations (RRES) have been devised in order to provide
	the systems with the needed temporal isolation. By introducing a
	RRES-aware scheduler in the context of a microkernel-based system,
	we may enrich it with the temporal benefits it needs in order to
	be deployed within domains with real-time requirements. 
	
	In this paper we propose a generic way to implement these mechanisms,
	dependent for a very small part on the underlying OS mechanisms.
	In order to show the generality of our RRES framework we implemented
	it in the context of Minix 3, a highly dependable microkernel-based
	OS with an impressive users base.},
  doi = {10.1007/s11241-009-9086-5},
  file = {:/home/jester/mydev/invoker-of-background-commands/doc/pdf/Mancina2009.pdf:PDF},
  issn = {0922-6443},
  issue = {2},
  keywords = {Operating systems; Real-time systems; Resource reservations; Micro-kernel;
	Dependability},
  language = {English},
  owner = {lucky},
  publisher = {Springer US},
  timestamp = {2012.12.27},
  url = {http://dx.doi.org/10.1007/s11241-009-9086-5}
}

@ELECTRONIC{Microsoft2012,
  author = {Microsoft},
  year = {2012},
  title = {Task Class},
  organization = {Microsoft Corporation},
  url = {http://msdn.microsoft.com/en-us/library/system.threading.tasks.task.aspx},
  file = {:/home/jester/mydev/invoker-of-background-commands/doc/html/MicrosoftTaskClass_System.Threading.Tasks.html:URL},
  owner = {lucky},
  timestamp = {2012.12.27}
}

@INPROCEEDINGS{Popovic2000,
  author = {Popović, D. S.},
  title = {Power Applications - A Cherry on the Top of the DMS Cake},
  booktitle = {Proceedings of the DA/DSM DistribuTECH Europe 2000},
  year = {2000},
  abstract = {An expert system, a distribution management system of power applications,
	is presented in this paper. The proposed system consists of 26 mutually
	compatible power applications, organised as modular libraries. They
	are integrated in the distribution management system as a unified
	software package used in four operation modes: operation management,
	operation planning, development planning and analysis, simulation
	and training. All power applications are developed on the basis of
	specialised algorithms aimed for distribution networks. This expert
	system provides, on one hand, an increase of the quality and quantity
	of delivered energy, and on the other hand, it decreases operating
	costs and enables investment postponement. In this way, the proposed
	expert system of power applications significantly increases the profits
	from investments into distribution networks, with relatively small
	cost compared to other investments.},
  file = {:/home/jester/mydev/invoker-of-background-commands/doc/pdf/Popovic2000.pdf:PDF},
  owner = {lucky},
  timestamp = {2012.12.27},
  url = {http://www.ist-world.org/ResultPublicationDetails.aspx?ResultPublicationId=34ad5cb73d494adfac0b596536d6303d}
}

@MISC{rfc793,
  author = {J. Postel},
  title = {{Transmission Control Protocol}},
  howpublished = {RFC 793 (Standard)},
  month = sep,
  year = {1981},
  note = {Updated by RFCs 1122, 3168, 6093, 6528},
  abstract = {PREFACE
	
	
	This document describes the DoD Standard Transmission Control Protocol
	
	(TCP). There have been nine earlier editions of the ARPA TCP
	
	specification on which this standard is based, and the present text
	
	draws heavily from them. There have been many contributors to this
	work
	
	both in terms of concepts and in terms of text. This edition clarifies
	
	several details and removes the end-of-letter buffer-size adjustments,
	
	and redescribes the letter mechanism as a push function.
	
	
	 Jon Postel
	
	
	 Editor
	
	
	
	1. INTRODUCTION
	
	
	The Transmission Control Protocol (TCP) is intended for use as a highly
	
	reliable host-to-host protocol between hosts in packet-switched computer
	
	communication networks, and in interconnected systems of such networks.
	
	
	This document describes the functions to be performed by the
	
	Transmission Control Protocol, the program that implements it, and
	its
	
	interface to programs or users that require its services.},
  file = {TCP:rfc\\rfc793.txt:Text},
  number = {793},
  organization = {Internet Engineering Task Force},
  owner = {nebojsa.trninic},
  publisher = {IETF},
  series = {Request for Comments},
  timestamp = {2012.05.14},
  url = {http://www.ietf.org/rfc/rfc793.txt}
}

@TECHREPORT{Rhodes2012,
  author = {Randy Rhodes, Zarko Sumic},
  title = {MarketScope for Advanced Distribution Management Systems},
  institution = {Gartner},
  year = {2012},
  number = {G00229447},
  month = {21 March},
  abstract = {We assess vendor capabilities and product offerings for global energy
	and utility buyers of emerging advanced distribution management system
	software.},
  file = {Rhodes2012.pdf:pdf\\Rhodes2012.pdf:PDF},
  owner = {nebojsa.trninic},
  review = {Referencirati na Gartner 2012. report "MarketScope for Advanced Distribution
	Management Systems". Npr. strana 6 od 23 ima dobrog teksta na temu
	kako DMS mora biti integrisan sa SCADAom i OMSom.},
  timestamp = {2012.06.03},
  url = {http://www.gartner.com/id=1957415}
}

@ELECTRONIC{Richardson2001,
  author = {Tristan Richardson},
  month = {11},
  year = {2001},
  title = {The OMNI Thread Abstraction},
  organization = {AT\&T Laboratories Cambridge},
  note = {Revised November 2001},
  url = {http://omniorb.sourceforge.net/},
  abstract = {The OMNI thread abstraction is designed to provide a common set of
	thread operations
	
	for use in programs written in C++. Programs written using the abstraction
	
	should be much easier to port between different architectures with
	different underlying
	
	threads primitives.
	
	The programming interface is designed to be similar to the C language
	interface
	
	to POSIX threads (IEEE draft standard 1003.1c—previously 1003.4a,
	often known
	
	as “pthreads” [POSIX94]).
	
	Much of the abstraction consists of simple C++ object wrappers around
	pthread
	
	calls. However for some features such as thread-specific data, a better
	interface can
	
	be offered because of the use of C++.
	
	Some of the more complex features of pthreads are not supported because
	of
	
	the difficulty of ensuring the same features can be offered on top
	of other thread
	
	systems. Such features include thread cancellation and complex scheduling
	control
	
	(though simple thread priorities are supported).},
  file = {Richardson2001.pdf:pdf\\Richardson2001.pdf:PDF},
  owner = {nebojsa.trninic},
  timestamp = {2012.06.07}
}

@INPROCEEDINGS{Scott2002,
  author = {Scott, Michael L.},
  title = {Non-blocking timeout in scalable queue-based spin locks},
  booktitle = {Proceedings of the twenty-first annual symposium on Principles of
	distributed computing},
  year = {2002},
  series = {PODC '02},
  pages = {31--40},
  address = {New York, NY, USA},
  publisher = {ACM},
  abstract = {Queue-based spin locks allow programs with busy-wait synchronization
	to scale to very large multiprocessors, without fear of starvation
	or performance-destroying contention. Timeout-capable spin locks
	allow a thread to abandon its attempt to acquire a lock; they are
	used widely in real-time systems to avoid overshooting a deadline,
	and in database systems to recover from transaction deadlock and
	to tolerate preemption of the thread that holds a lock.In previous
	work we showed how to incorporate timeout in scalable queue-based
	locks. Technological trends suggest that this combination will be
	of increasing commercial importance. Our previous solutions, however,
	require a thread that is timing out to handshake with its neighbors
	in the queue, a requirement that may lead to indefinite delay in
	a preemptively multiprogrammed system.In the current paper we present
	new queue-based locks in which the timeout code is non-blocking.
	These locks sacrifice the constant worst-case space per thread of
	our previous algorithms, but allow us to bound the time that a thread
	may be delayed by preemption of its peers. We present empirical results
	indicating that space needs are modest in practice, and that performance
	scales well to large machines. We also conjecture that constant per-thread
	space cannot be guaranteed together with non-blocking timeout in
	a queue-based lock.},
  acmid = {571830},
  doi = {10.1145/571825.571830},
  file = {Scott2002.pdf:pdf\\Scott2002.pdf:PDF},
  isbn = {1-58113-485-1},
  keywords = {scalability, spin locks, synchronization, timeout},
  location = {Monterey, California},
  numpages = {10},
  owner = {nebojsa.trninic},
  review = {...
	
	Many of these applications
	
	depend critically on the ability of a thread that waits "too
	
	long" to time out and abandon its attempt to acquire a lock.
	
	Timeout-capable "try locks" allow a real-time application to
	
	signal an error condition or pursue an alternative code path.
	
	In a database system, they provide a simple means of recovering
	
	from transaction deadlock.
	
	....
	
	
	ntrna>>> Reference na 80-te i 90-te tako da je veoma star rad. Pokazuju
	da razni
	
	mehanizmi račključavanja imaju različite performanse, koje su čak
	stohastičke, ako
	
	se npr. koristi zaključavanje sa timeout-om.},
  timestamp = {2012.05.16},
  url = {http://doi.acm.org/10.1145/571825.571830}
}

@MISC{rfc1350,
  author = {K. Sollins},
  title = {{The TFTP Protocol (Revision 2)}},
  howpublished = {RFC 1350 (Standard)},
  month = jul,
  year = {1992},
  note = {Updated by RFCs 1782, 1783, 1784, 1785, 2347, 2348, 2349},
  abstract = {TFTP is a very simple protocol used to transfer files. It is from
	
	 this that its name comes, Trivial File Transfer Protocol or TFTP.
	
	 Each nonterminal packet is acknowledged separately. This document
	
	 describes the protocol and its types of packets. The document also
	
	 explains the reasons behind some of the design decisions.},
  file = {rfc1350.txt:rfc\\rfc1350.txt:Text},
  number = {1350},
  organization = {Internet Engineering Task Force},
  owner = {nebojsa.trninic},
  publisher = {IETF},
  series = {Request for Comments},
  timestamp = {2012.05.20},
  url = {http://www.ietf.org/rfc/rfc1350.txt}
}

@INPROCEEDINGS{Wiesmann2000,
  author = {Wiesmann, M. and Pedone, F. and Schiper, A. and Kemme, B. and Alonso,
	G.},
  title = {Understanding Replication in Databases and Distributed Systems},
  booktitle = {Proceedings of the The 20th International Conference on Distributed
	Computing Systems ( ICDCS 2000)},
  year = {2000},
  series = {ICDCS '00},
  pages = {464--},
  address = {Washington, DC, USA},
  publisher = {IEEE Computer Society},
  abstract = {Replication is an area of interest to both distributed systems and
	databases. The solutions developed from these two perspectives are
	conceptually similar but differ in many aspects: model, assumptions,
	mechanisms, guarantees provided, and implementation. In this paper,
	we provide an abstract and ¿neutral¿ framework to compare replication
	techniques from both communities. The framework has been designed
	to emphasize the role played by different mechanisms and to facilitate
	comparisons. The paper describes the replication techniques used
	in both communities, compares them, and points out ways in which
	they can be integrated to arrive to better, more robust replication
	protocols.},
  acmid = {851782},
  file = {:/home/jester/mydev/invoker-of-background-commands/doc/pdf/Wiesmann2000.pdf:PDF},
  isbn = {0-7695-0601-1},
  owner = {lucky},
  timestamp = {2012.12.27},
  url = {http://dl.acm.org/citation.cfm?id=850927.851782}
}

@ELECTRONIC{fieldbus01,
  year = {2012},
  title = {Weighing Systems - Fieldbus Overview},
  organization = {Industrial Networking and Open Control},
  address = {PO Box 376
	
	Blackheath
	
	London
	
	SE3 8BE
	
	UK},
  note = {Phone 01462 450626 Fax 01462 420448},
  url = {http://www.weighing-systems.com/TechnologyCentre/fieldbus1.html},
  abstract = {There have emerged literally hundreds of fieldbuses developed by different
	companies and organisations all over the world. The term fieldbus
	covers many different industrial network protocols. Most fieldbus
	protocols have been developed and supported by specific PLC manufacturers.
	The accompanying table summarises some of the main ones.},
  file = {Fieldbus01:html\\09_Fieldbus overview.htm:URL},
  keywords = {fieldbus, profibus, modbus, devicenet, interbus, CANbus, ethernet,
	TCP/IP},
  owner = {nebojsa.trninic},
  review = {Foundation Fieldbus is a sophisticated, object-oriented protocol that
	uses multiple messaging formats and allows a controller to recognize
	a rich set of configuration and parameter information ("device description")
	from devices that have been plugged into the bus. Foundation Fieldbus
	even allows a device to transmit parameters relating to the estimated
	reliability of a particular piece of data. Foundation Fieldbus uses
	a scheduler to *** guarantee the delivery of messages, so issues
	of determinism and repeatability are solidly addressed (determinism
	means knowing absolute worst-case response times with 100% certainty)
	***. Each segment of the network contains one scheduler.
	
	
	...
	
	
	Against this backdrop, frustrating for many, came the re-emergence
	of the Ethernet. Ten years ago, no serious design engineer would
	have suggested using Ethernet for networking factory floor devices.
	Ethernet, the technology for office automation, was developed more
	than 20 years ago as a high-speed serial data-transfer network. It
	has become a worldwide standard and is now the most widely used Local
	Area Network (LAN) in existence. More than 85% of all installed network
	connections in the world are Ethernet. But it was deliberately ignored
	for industrial applications, and for good reasons; its lack of determinism
	and robustness made it a feeble, unpredictable companion for the
	shop floor. Yet today, the scene has almost reversed. Why such a
	radical change? Over the past few years there have been many enhancements
	to the Ethernet standard, especially in areas of determinism, speed,
	and message prioritisation. So there is no longer any reason why
	Ethernet cannot be used to build deterministic fieldbus networks
	that are cost-effective and open. And since Ethernet is already the
	network choice for business computing, its presence at the control
	level will make sensor-to-boardroom integration a reality. Another
	good reason manufacturers are looking at Ethernet is the coming explosion
	of factory floor data traffic. As smart sensors and various devices
	on the plant floor eat up the available bandwidth over the next four
	years, manufacturing plant information generated by PLCs and control
	systems is expected to increase from 10 to 30 times the current level.
	Ethernet, with its Internet-friendly TCP/IP protocol, is ideally
	positioned. It is popular, plummeting in price and being propelled
	by sheer market demand.
	
	
	So Ethernet is poised to penetrate deep into the factory network hierarchy,
	down to the I/O level. That makes some programmable controller (PLC)
	manufacturers uncomfortable. Even the recently arrived fieldbus systems
	are beginning to feel the impact - some say threat - of Ethernet.
	Furthermore, the DeviceNet, Profibus and Foundation Fieldbus protocols
	are all available or in development as application layers for Ethernet.
	And most PLCs now offer Ethernet as a standard networking option
	in addition to their fieldbus of choice. High Speed Ethernet (HSE)
	is a 100 Mbit Ethernet standard that uses the same protocol and objects
	as Foundation Fieldbus H1, on TCP/IP. The next generation of Ethernet
	is called Gigabit Ethernet, which is capable of 1 Gbits/sec). This
	will bridge the gap between the necessity of industrially hardened
	wiring capability and the growing need for process data via business
	LANs and the Internet. Most firms cannot afford to have a DeviceNet
	or Profibus specialist on staff who thoroughly understands the network
	protocol. Even if a company could afford such a person, it is unlikely
	fieldbus would be their specialty. However, almost every company
	has a network administrator who is well versed and specialises in
	Ethernet protocol, making Ethernet all the more attractive for industrial
	control.},
  timestamp = {2012.06.04}
}

@ELECTRONIC{fieldbus02,
  year = {2012},
  title = {Fieldbus},
  url = {http://en.wikipedia.org/wiki/Fieldbus},
  abstract = {Fieldbus is the name of a family of industrial computer network protocols
	used for real-time distributed control, now standardized as IEC 61158.
	
	A complex automated industrial system — such as manufacturing assembly
	line — usually needs an organized hierarchy of controller systems
	to function. In this hierarchy there is usually a Human Machine Interface
	(HMI) at the top, where an operator can monitor or operate the system.
	This is typically linked to a middle layer of programmable logic
	controllers (PLC) via a non-time-critical communications system (e.g.
	Ethernet). At the bottom of the control chain is the fieldbus that
	links the PLCs to the components that actually do the work, such
	as sensors, actuators, electric motors, console lights, switches,
	valves and contactors.},
  file = {Fieldbus02:html\\10_Fieldbus - Wikipedia, the free encyclopedia.htm:URL},
  owner = {nebojsa.trninic},
  review = {Current developments
	
	
	Recently a number of Ethernet-based industrial communication systems
	have been established, most of them with extensions for *** real-time
	communication ***. These have the potential to replace the traditional
	fieldbuses in the long term.
	
	
	Here is a partial list of the new Ethernet-based industrial communication
	systems:
	
	EtherCAT
	
	EtherNet/IP
	
	Ethernet Powerlink
	
	BACnet
	
	PROFINET IO
	
	PROFINET IRT
	
	SafetyNET p
	
	SERCOS III
	
	TTEthernet
	
	VARAN
	
	RAPIEnet
	
	For details, see the article on Industrial Ethernet},
  timestamp = {2012.06.05}
}

@comment{jabref-meta: selector_review:}

@comment{jabref-meta: selector_publisher:}

@comment{jabref-meta: selector_author:}

@comment{jabref-meta: selector_journal:}

@comment{jabref-meta: selector_keywords:}

